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Abstract — The requirements roadmap concept is introduced 
as a solution to the problem of the requirements engineering 
of adaptive systems. The concept requires a new general 
definition of the requirements problem which allows for quan- 
titative (numeric) variables, together with qualitative (binary 
boolean) propositional variables, and distinguishes monitored 
from controlled variables for use in control loops. We study the 
consequences of these changes, and argue that the requirements 
roadmap concept bridges the gap between current general 
definitions of the requirements problem and its notion of 
solution, and the research into the relaxation of requirements, 
the evaluation of their partial satisfaction, and the monitoring 
and control of requirements, all topics of particular interest in 
the engineering of requirements for adaptive systems |3|. From 
the theoretical perspective, we show clearly and formally the 
fundamental differences between more traditional conception 
of requirements engineering (e.g., Zave & Jackson |16|) and 
the requirements engineering of adaptive systems (from Fickas 
& Feather |6|, over Letier & van Lamsweerde |9|, and up 
to Whittle et al. |14| and the most recent research). From the 
engineering perspective, we define a proto-framework for early 
requirements engineering of adaptive systems, which illustrates 
the features needed in future requirements frameworks for this 
class of systems. 

Arejivorrfs -requirements roadmap, requirements problem, 
adaptive systems, relaxation of requirements, monitoring 

I. Introduction 

There is a growing interest in the requirements engineering 
(re) of adaptive systems, whose salient feature is the ability to 
adjust behavior in response to requirements and environment 
variations. The robustness and versatility that these systems 
promise will likely result in future sustained investment in 
theoretical and applied RE research. 

The salient feature of research in RE of adaptive systems is 
disconnectedness (see Cheng et al. [3] for a general overview, 
Whittle et al. liT4l for a recent and comprehensive list of 
references in RE). This reflects the very novelty of this class 
of systems, so that mature results were not to be expected. 
But disconnectedness causes a number of very practical 
problems which should be discussed already now, reflected 
by such general questions as "How exactly is RE for this 
class of systems different from established RE?", "How do 
the inputs and outputs of RE for adaptive systems differ from 
those in established re?", as well as more specific ones, e.g., 



"What should we keep, remove from, or add to existing RE 
modeling languages/frameworks/methodologies to use them 
for RE of adaptive systems?". 

The aim of this paper is to give clear and formal answers 
to these questions, and thereby help connect existing research, 
inform future work, move closer to a deeper classification of 
research in RE of adaptive systems, and help skeptics decide 
if/how novel is the problem posed to RE by adaptive systems. 

To reach this aim, we illustrate and define the requirements 
problem for adaptive systems, using a formalism which is just 
expressive enough to include concepts and relations already 
appearing in RE, and which includes features central for RE of 
adaptive systems: (i) monitoring and control of requirements 
(following Fickas & Feather [6], Feather et al. |5|, and 
Robinson 111]); (ii) probabilistic relaxation of requirements 
(Letier & van Lamsweerde JU); (iii) fuzzy relaxation of 
requirements (Whittle et al. f\A\ and Baresi et al. |2|); and (iv) 
adaptation requirements (Souza et al. |13|). It turns out that 
extending the simple, but abstract modeling language Techne 
Q to allow constraints over quantitative (numerical) variables 
is enough to capture key ideas in monitoring, relaxation, 
and adaptation, and to show how they participate in the 
requirements problem of adaptive systems. 

This paper presents two main contributions: 

• The requirements problem for adaptive systems and its 
solution concept, called requirements roadmap (roadmap 
hereafter), are formally defined. A roadmap amounts 
to a sequence of requirements configurations, each of 
which is shown to satisfy all properties required by 
Zave & Jackson |16|, and in our prior work |8|. These 
parallels show exactly how the problem and roadmap 
concepts are different from more traditional RE. 

• To introduce the problem and roadmap concepts, we 
define a simple formalism in which we can model (i) 
probabilistic and fuzzy relaxation, (ii) monitored and 
controlled variables, (iii) adaptation requirements. It is 
a proto-framework for RE because (a) it is impractical 
in its current form, but is enough to allow us to present 
and discuss the salient properties of the problem and 
roadmap concepts, and (b) it can serve as a prototype 
for early formal modeling languages for RE of adaptive 
systems. 



We use the London Ambulance Service (LAS) case study 
PI to recall and illustrate the key notions from prior work 
that we mentioned above (pB, then to informally illustrate 



the new problem and roadmap concepts (^IIIl. We discuss 



their departure from prior work (^IVi, and present the 
formalization of the concepts and relations used to define 
these concepts and model there instances throughout the 
paper (j |V|. Finally, we summarize conclusions and open 
issues (§VI|l. 

II. Baseline & Related Work 

We discuss in this section how earlier contributions in RE 
- concerning monitoring and control, probabilistic relaxation, 
and fuzzy relaxation - influence the understanding of the 
requirements problem and its solutions for adaptive systems. 

A. Background 

We assume that requirements are either prepositional 
variables or constraints on quantitative variables, which are 
categorized according to the core ontology [SJ, and that 
relations are formalized as in Techne Q; a requirement is 
k: a domain assumption if it states a value that a variable 
is believed to have; e.g., in Figure [T]^a), k(ri) is a 
domain assumption over a prepositional, qualitative 
variable, while in Figure [ijd), k{ii{tx) = 0.6) is a 
domain assumption over a quantitative variable, the 
value of a function /i; 
g: a goal if it identifies a desirable value of a qualitative 
variable, i.e., it states a property that we want to see 
holding; e.g., 9(^2) in Figure [TJa); 
q: a quality constraint if it places a constraint on desirable 
values of a quantitative variable; e.g., in Figure [ijd), 
q{tx = 60sec) says that the desirable value of is 
60sec; 

s: a softgoal if it refers to a desirable value of a variable 
in such a way that it is not possible to identify exactly 
which value, or range of values of that variable it refers 
to; e.g., in Figure [l|d), s(wi) is a softgoal. 
t: a task if the prepositional variable in it says what to 

do; e.g., in Figure [TJ a), t(Mi) is a task. 
A requirement can be mandatory, optional, or neither. 
9(<Z2)" is a mandatory goal, which means that it must be 
satisfied. 9(^15)° is an optional goal, meaning that it is more 
desirable that it is satisfied, than not, but we will still accept a 
system which fails to satisfy 9(^15)°. Requirements can be in 
three binary or n-ary relations. The directed arrow in Figure 
[Tfa) represents the inference relation fT^, also understood 
as a conditional, if-then relation, so that the line from t(iti) 
to 9(p2) abbreviates the formula k(t(ui) — >■ 9(^2)). i-e-> a 
domain assumption according to which, if we can deduce 
t(ui), then we can also deduce 9(^2), or in other words, t(wi) 
operationalizes 9(^2)- The inference relation stands for opera- 
tionalization when it goes from tasks and domain assumptions 
to goals; otherwise, it can be read as a refinement: in Figure 



[TJa), k(k(ri)Ak(r2)Ag(pi)A9(p2)A9(P3)A9b4) ^ 9(92)") 
says that the domain assumptions k(ri) and k(r2), and the 
goals q{pi) to 9(^4) refine Q{q2)"- Logically inconsistent 
requirements are in the conflict relation: e.g., we assume 
in Figure [ij a) that 1(^2) cannot be satisfied together with 
1(1*4), which we draw with the bulleted line between them, 
and this abbreviates the assumption k(t(w2) A 1(^4) — _L): 
if we can deduce both, then we will also conclude logical 
inconsistency. Finally, we can have a preference relation 
between requirements: e.g., t(uio) >- t(ui3) in Figure [ijd) 
reads that satisfying t(uio) is strictly more desirable than 
satisfying 1(1*13). 

B. Monitoring, Control, Probabilistic & Fuzzy Relaxation 

Enabling adaptive behavior requires the monitoring of 
requirements and control of behaviors intended to satisfy 
requirements. Fickas & Feather f6^| suggested that for 
this we must start with a specification of all alternative 
behaviors to be considered in a requirments model, that 
is, alternative refinements and operationalizations of all 
requirements. The model is then a source of monitored 
variables, the observed values of which will trigger behaviors, 
called reconciliation tactics, that are intended to change 
the values of control variables, which can affect how one 
operationalizes a requirement. This forms a control loop, 
through which the system observes and reacts by switching 
from one runtime configuration to another. For illustration, 
consider the goal 9(^3 : Check if double location) for LAS 
in Figure [TJa), which is operationalized via two refinements: 
one way to satisfy 9(^3) is by executing both tasks 1(1*2) and 
1(^3), the other is via 1(1*4). A reconciliation tactic could 
be, e.g., if 1(^2) fails, then operationalize 9(^3) by 1(1*4). 
Feather et al. Q combined the requirements monitoring 
mechanisms from Fickas & Feather with KAOS |4| to make 
an RE framework, where requirements can be converted into 
constraints on events, and events are monitored at runtime. 
Robinson flTIl suggested a requirements monitoring platform 
that can be combined with a requirements modeling language 
via translation rules between the expressions of the latter 
and those accepted by the former, then suggested how to use 
OCL as the modeling language for the platform |12|. 

An important characteristic of a reconciliation tactic (and 
same applies to adaptation goals Q), is that it is defined 
in relation to local requirements, i.e., it says what to do 
in relation to a single requirement which is not being 
satisfied. There are two problems with defining adaptation 
requirements by looking mainly at local requirements. First, 
it is not clear that following any or every reconciliation 
tactic will make sure that the new system configuration is 
consistent with the requirements. It is not clear what happens 
if the reconciliation tactic works locally, but activates, e.g., 
tasks which are inconsistent with some other already active 
part of the system. The other problem is that one local 
change may seem fine by itself, and may result in a new 



(a) Early qualitative requirements 

'{q2: Emergency calls are responded to) 

— k(r1 : Every call is switched to the ambulance dispatch center) 1 

k(r2: No calls are dropped because of timeout) -i 

g(p1; Receive emergency call) < ' ' 

g(p2; Identify incident locations) 

- g(p12; Incident location identified automatically) 

k (r3: Callers report imprecise incident location) 

I t(u1; Make the map searchable through the dispatch software) 

' g(p13: Manually identify location using paper map) 

g(p3; Check if double location) 

g(p14; Dispatch software aids the identification of duplicate calls ) 

A 

t(u2; List of open incident locations incidents visible in the 
dispatch interface) 

t(u3: Update the list of open incident locations every time 
an open incident is added) 
t(u4: Every control assistant manually keeps track of locations 
of open incidents) 

' g(p4: Fill out incident report) 

t(u5; Fill out incident report via the software) • — i 



- t(u6: Fill out a paper incident report form) • ' 

g"(q1: Ambulances arrive at their incident locations) 

- g(p5; Identify available ambulances) 

t(u7; Make the list of all available and of all allocated ambulances 
available through the dispatch interface ) 

t(u8; Update the list of ail available and of all allocated ambulances 
every time an ambulance is assigned to an Incident ) 

I t(u9: Every control assistant manually keeps track of available ambulances ) 

- g(p6; Choose ambulance) 

t(u10: Dispatch software ranks available ambulances from the most 
appropriate for the incident location to the least appropriate ) 
t(u11: Dispatch software displays the ranking of available 
ambulances to the control assistant) 

t(u12: Control assistant chooses herself/himself an ambulance 

— among available ambulances) 

k(r4: Control assistants use heuristics that are difficult to automate when 
choosing an ambulance) 

t(u13: Dispatch software makes no recommendations to the control 
assistant on which ambulance to choose) 

- g(p7; Assign ambulances) 

^ t(u14: Control assistant uses the dispatch software to select one of the 

available ambulances and assign it to the incident) 
t(u15: Control assistant verbally communicates to all other control 
assistants which ambulance was chosen for assignment to the incident ) 

- g(p8; Mobilize ambulances) 
t(u16: Control assistant mobilizes the ambulance through radio 

communication with the staff in the ambulance ) 

t(u17: Control assistant uses the dispatch software to mobilize the 
ambulance without talking to the staff in the ambulance ) 



(b) Mandatory goals 



(c) Req. configurations 



(d) Comparison criteria 



- g(p9; Confirm mobilization) 

^ t(u18: Staff in the ambulance uses the dispatch software client in the 

ambulance to confirm mobilization at the given incident location ) 

g(p10: Receive confirmation of arrival to incident location) 

4 ^ t(u19: Staff in the ambulance uses the dispatch software client in the 

ambulance to confirm the arrival at the incident location ) 

I t(u20: Staff in the ambulance use the radio to confirm the arrival at the 

incident location) 
g(p11: Close incident report form) 



t(u21: Close the incident report via the software) • 

- t(u22: Manually dose and put aside a paper incident report form ) 

— g°(p15: Paper is not used in the control room) 
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Legend 
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Conflict 



Mandatory requirement 
Optional requirement 



g; Goal 

k; Domain assumption 
t: Task 



q: Quality constraint 
s: Softgoal 



-> See text for interpretation. 



t(u21) > 
t(u22) 



Task t(u21 ) is strictly preferred to task t{u22). 



Figure 1. Simple early requirements, requirements configurations, and comparison criteria for LAS. 



and consistent configuration, but this new configuration may 
be a dominated one: i.e., maybe instead of satisfying one 
adaptation requirement and obtaining some quality level, 
we could have used several adaptations, which result in a 
configuration that ensures higher quality. The local approach 



to the definition of adaptation requirements comes with the 
risk of adapting to a sub-optimal or inconsistent configuration. 

We therefore contend that instead of defining adaptation 
requirements by considering their impact only on a small set 
of requirements, adaptation requirements should be defined so 



as to ensure that the configuration obtained after adaptation 
is desirable in its entirety in terms of various criteria 
used to compare alternative requirements configurations 
(including, for example, preferences over requirements, 
probabilities of requirements satisfaction, and so on). This 
has two consequences on the formulation of the problem and 
solution concepts in adaptive system requirements. First, it 
follows that we do not define adaptation requirements while 
writing the requirements model, but compute them after we 
have identified at least some configurations from a set of 
alternatives, all of which satisfy some set of properties (e.g., 
are consistent) and satisfy some preferrence requirements. 
Consider Figure [TJc), where each column 5*1, S2, and 6*3 is 
a different requirements configuration, and each satisfies the 
mandatory goals set in Figure [Tf a) for the LAS system: e.g., 
if the system is configured according to Si, and 1(^5) fails, 
then it may be more desirable to adapt to 6*3 than to S2, 
so that adaptation requirements can be identified directly by 
comparing Si to 5*3, and defined as the switch from t(u2i) 
to \{u22), from t(ui9) to t(u2o), from t(ui7) to t(ui6), and 
from 1(1/5) to \{uq). Secondly, the local/global distinction has 
an impact on how we select configurations: it is likely that the 
system can adapt from one to one among several alternative 
configurations; e.g., if 1(^17) fails in Figure [TJc), both S2 
and 5*3 use the alternative t(ui8). Selection should take into 
account the consequences of adapting to a configuration: e.g., 
perhaps configuration Si is more desirable than S2 if only 
these two are compared, but we may know that if we select 
Si, then in the long term, e.g., it is not sustainable, in order 
to keep satisfying some quality constraint. This means that 
there can be preferences over sequences of configurations. 

Adaptive behavior by definition means that the system 
cannot satisfy all the specific requirements and meet the 
desired quality levels, all of the time - it may do worse, 
but it may also do better. Relaxation of requirements has 
been suggested to cover both cases: a requirement can be 
relaxed to allow the system to fail it, but we restrict how 
often it can do so (via probabilistic relaxation), or to avoid 
overly constraining the system when it may deliver higher 
quality than expected (via fuzzy relaxation). Relaxation of 
requirements is closely related to the evaluation of their 
satifaction, as one aim of relaxation is to quantify the degree 
of satisfaction of a requirement. Two broad approaches to 
relaxation and satisfaction evaluation have been suggested, 
based on objective criteria (where quantification is in terms 
of measurable phenomena in the environment or the system) 
or on subjective criteria (where a number is given to reflect 
personal impression of satisfaction, regardless of measurable 
phenomena in the domain). 

An important approach to relaxation, based on objective 
criteria, appears in Letier & van Lamsweerde [9], who 
extended goal models from KAOS to allow the specification of 
measures on system behaviors, and probability functions over 
the values of these measures. Using such a formalism, they 



can state, e.g., that in the LAS system, 95% of ambulances 
should reach the designated place of incident in at most 14 
minutes after an incident is reported. Values of measures 
and probabilities are computed for every requirements 
configuration, all of which are inputs to a decision-making 
process that aims at selecting a single configuration. 

Approaches based on subjective criteria were revived re- 
cently for RE of adaptive systems. Whittle et al. 1 14| associate 
fuzzy membership functions to qualitative requirements, in 
order to allow and quantify departures from the ideal satisfac- 
tion of such requirements. The fuzzy membership function 
can be interpreted as a satisfaction function, and they use 
modalities to relax requirements: e.g., to relax the task t(Mi8) 
in Figure [T| we would write [As early as possible]t(ui8). 
This means that there is a function fi which returns a level 
of satisfaction when given a duration between time "now" 
and the time when t(Mi8) is executed, whereby ji "has its 
maximum value at (i.e., at the current point in time) 
[and] tails off gradually ad infinitum (i.e., it has a triangular 
membership graph that is asymptotic)" |14|. 

Baresi et al. |2| also use fuzzy membership functions 
to treat qualitative requirements as quantitative ones. They 
introduce degrees of satisfaction between the binary (for 
violated) and 1 (satisfied); thus, adjusted requirements are 
associated to "adaptive" requirements that relate ranges of 
values of the fuzzy membership function to trigger switching 
between configurations. For example, if there is a quality 
constraint q(w < 6hrs) here (a goal Q{v < 6hrs) for them, 
as they allow quantitative variables in goals), then relaxing 
it would amount to replacing it with q(7; </ 6hrs) (in their 
notation, Q{v <f 6hrs)), where </ is a fuzzy operator. 
Their interpretation of v <f 6hrs is that there is a fuzzy 
membership function /i which returns the level of satisfaction 
as a function of v, and the shape of /i is predefined (for < f 
in Q{v <f 6hrs), it is positive and constant until v — Q, then 
decreases up to the satisfaction value for some v > 6). 

III. RPAS & RoADMAP Concepts 

The requirements problem for adaptive systems (RPAS) and 
the corresponding roadmap concept need to be introduced 
because monitoring, control, adaptive requirements, and 
probabilistic and fuzzy relaxation cannot be formulated in 
the traditional requirements problem and solution framework: 
these features add information to the requirements problem, 
which in turn affects the properties that solutions need to 
satisfy, and influence the criteria used to compare alternative 
solutions. The aim of this section is to present and discuss the 
properties of the roadmap concept, as the solution concept 
for RPAS; we later compare RPAS and roadmap concepts to 
Zave & Jackson fT6l and Techne |8| (cf., 

A. Requirements Problem for Adaptive Systems 

The requirements problem is a design and decision-making 
problem. By design, we mean that alternative solutions to 



the problem are not available, but need to be created: e.g., in 
Figure [TJa), we start from two broad goals, g{qi) and 9(92), 
so that we need to elicit further requirements and information, 
refine goals, identify conflicts, define operationalizations, all 
of which fall under design Decision-making requires the 
identification of criteria for the comparison of alternative 
solutions, and the application of a decision rule to rank 
alternative solutions from the most desirable to the least 
desirable. 

To provide definitions, we start with the notion of a 
requirements database A — a set of requirements (i.e., 
domain assumptions, goals, quality constraints, softgoals, 
tasks) and relations between them (e.g., conjunction, in- 
ference, refinement, conflict, preference). For example, the 
requirements database for LAS in this paper includes all 
labeled propositions in Figure [T] 

For the remaining definitions, we start at the end (RPAS), 
and explain one by one its component definitions. Hence 
definitions unfold recursively. 

RPAS is the problem of designing and ranking roadmaps. 

Definition III.l. The requirements problem for adaptive 
systems: Given a requirements database A, design, find, 
and rank roadmaps that can be defined from A. 

A roadmap is a sequence of requirements configurations 
and adaptation requirements needed to switch between these 
configurations. 

Definition III.2. A requirements roadmap is a pair TZ = 
{S,A), where S = (5i,...,S'„) is a sequence of n 
requirements configurations and A is a set of adaptation 
requirements. 

The novelty of the problem and roadmap concepts lies 
in the properties of requirements configurations, adaptation 
requirements, and in how roadmaps can be ranked. We discuss 
these in turn below. 

B. Properties of Requirements Configurations 

Let us first look at the configurations appearing in a 
roadmap. 

Definition III.3. A configuration in a roadmap is a set 
S of domain assumptions and tasks in A such that S 
satisfies the Consistency, Qualitative threshold achievement. 
Quantitative threshold achievement. Conformity, Dominance, 
and Minimality conditions defined below. 

1} Consistency: Every requirements configuration S must 
be consistent, i.e., S" _L, where is the Techne 
consequence relation Q. With consistency, the adaptive 

'Note that "design" is typically used for steps of systems development 
that come after RE, such as architectural design. The term "design" is 
used here in a broader sense, to encompass all activities (e.g., elicitation, 
validation) which are necessary to make alternative options on which we 
then need to decide. 



system should work to satisfy a consistent set of requirements. 
In Figure [Tfc), every configuration is such that there are no 
conflicts between its members. Remark that given a sequence 
S = (5*1, . . . , Sn) in a road map, [JS can, and will often 
be inconsistent, as consecutive configurations need not be 
consistent together. If we adapt from 5*1 to 5*2 in Figure 
[ijc), note that 5i U S'2 1^ -L' since there are conflicts, e.g., 
between t{uie) and t(ui7). 

2) Qualitative Threshold Achievement: Every configura- 
tion S should operationalize every mandatory goal in A — 
a set written as Ag. An operationlization defines tasks and 
domain assumptions from which we can deduce (via |-^) the 
goal. For example, in Figure[T|a), if the task t(ui) is satisfied, 
then 9(^2) is satisfied, so that the former operationalizes 
the latter. Since a requirement can be operationalized by 
alternative sets of tasks and domain assumptions, we have 
a function Op{f) which, which given a mandatory goal 
(p e Ag, returns the set of all operationalizations of (p. 
E.g., Op{g{pi)) includes two operationalizations of 9(^7) 
in Figure [ija). The property is restricted to qualitative 
requirements, for which satisfaction is binary, and thus to 
goals, since a goal is either satisfied or not. The property 
requires threshold satisfaction, since it requires only that all 
mandatory goals be satisfied by a configuration. 

A consistent set of requirements must meet both the 
qualitative and quantitative thresholds, for it otherwise fails 
to satisfy the requirements which must be satisfied. 

3) Quantitative Threshold Achievement: Every config- 
uration Sshould operationalize every mandatory quality 
constraint in A. — a set written as Aq. Once again, the 
function Ov((^), returns all sets of operationalizations of 
quality constraint </? — (\{a), whereby some set 11 is such 
an operationalization iff it assigns values to variables in a 
which ensure that the constraint in a is satisfied. Quality 
constraints identify desirable values of quantitative variables. 
E.g., qs may thus place constraints on values of measures of 
some behavior of the system-to-be. In LAS, and in relation 
to the response to emergency calls and the mobilization of 
ambulances, the time that these activities take is a crucial 
part of quality of service. We can use the following variables, 
where c identifies a call and e a unique incident: 

t\^c'- Time the caller waits for a control assistant; 

t2^c'. Time to identify incident location; 

t^^c'. Time to fill out incident report; 

t4,y. Time to mobilize an ambulance; 

t^^e'- Time for the mobilized ambulance to arrive and 

confirm arrival at incident location. 

Instead of defining bounds on all of these variables, a 
government standard may not be as specific, and may impose 
a maximal time over a subset of activities that need to be 
executed between the placement of the emergency call and 
the confirmation of arrival of an ambulance to location; e.g.: 

^{t&.c < 3min: te.c is the duration between the 
switching of the call c to the dispatch center to the 
mobilization of the ambulance to the incident location;) 



where it is clear that the value of ^ depends on ti c, t2.c, 
t^^c and t4_e. If we assume that ig.c = ti.c + t2,c + ts.c + t^.e, 
then we add this to the requirements database as a domain 
assumption over quantitative variables, k(t6,c — ti.c + ^2,c + 
^s.c + i4,e)- The domain assumption says that there is a 
quantitative refinement relation between variables, and it 
specifies the functional relation between the refined tg.c and 
the variables refining it. In contrast to the refinement relation, 
quantitative refinement is not over requirements, but variables 
in requirements. 

While it may be useful to set a precise bound on the 
value of an aggregate variable, as tg.c above, it may be 
more interesting to set bounds relative to the values of other 
variables. E.g., if we want i2.c to be at most 110% of its 
average value over the past three months, then we write 

q(i2,c < (l.l/3)(Dl,m-3 + t'l,m-2 + t^l,m-l)); 

k(ui,,„ = n(m)"^ Z^rir' I]c=i *2,c), where m is the 
month identifier, n(m) the number of days in m, c 
is the call identifier on a given day, c{i) is the total 
number of calls received on day i of month m; 

where the domain assumption is a quantitative refinement of 
vi,m, the average time, over a month, that it takes to identify 
the location. 

The quality constraints and quantitative refinements need 
to be related to goals, tasks and domain assumptions in 
order to determine if the former are satisfied. If there is 
a rurming system, the values of i2,c are recorded, and 
it is straightforward to check if the constraint i2,c < 
(l.l/3)(i;i,„i_3 + Vi,„,-2 + wi,m-i) is satisfied. Before 
the system is in operation, we can simulate values of 
t2,c, by assuming that t2.c is a random variable which 
has some probability distribution, so that we would have 
k(i2,c N{msec,45sec^)) if we assume that t2.c follows 
a normal distribution with mean 60sec and variance 45sec^ 
when the task t(ui) is satisfied, which we model by a 
refinement k(t(wi) k(i2,c ^ A/^eOsec, 45sec^))). This 
assumption may be based on data from a pilot study, from 
expert opinion, or from data on systems which also satisfy 
t(ui) and are already in operation. 

4) Conformity: Every configuration S must include all 
strict domain assumptions and all mandatory tasks, i.e., 
Aj^ U Aj C S. This property asks that all strict domain 
assumptions are not violated and all mandatory tasks are 
executed in every configuration. 

The Qualitative and Quantitative threshold achievement 
and Conformity properties ensure that a configuration satisfies 
all that must be satisfied. 

5} Dominance: Every configuration S must be maximal 
w.r.t. optional requirements, i.e., ^S' C A such that (i) both 
satisfy the Consistency, Qualitative threshold achievement. 
Quantitative threshold achievement, and Conformity condi- 
tions, (ii) S C S', and (iii) S' \ S contains optional k or t 
requirements. 

This condition formalizes the idea of optional requirements, 



which are desirable to satisfy, but can be violated. A 
configuration should include as many such defeasible domain 
assumptions and as many optional tasks, up to the point at 
which adding any further defeasible domain assumptions 
and/or optional tasks violates the Consistency, Qualitative 
and Quantitative threshold achievement, and Conformity 
properties. The Dominance property ensures that every 
configuration is Pareto efficient with regards to optional 
requirements, as this condition makes it impossible to add 
optional domain assumptions and tasks to any S and still 
ensure that S" is a configuration. 

6) Minimality: A set S satisfying all the above properties 
must be minimal in order to qualify as a configuration. 
Minimality requires that a configuration includes only the 
domain assumptions and tasks which are needed to satisfy 
exactly the Consistency, Qualitative threshold achievement. 
Quantitative threshold achievement. Conformity, and Domi- 
nance properties. 

Configurations in Figure [TJc) satisfy all six properties. 

C. Adaptation Requirements, Monitoring & Control 

An adaptation requirement is meant to constrain suc- 
cessive configurations in a roadmap. It does so by de- 
scribing the presence/absence of certain requirements in 
pairs of related configurations, and is triggerred by the 
failure of monitored assumptions, tasks, or quality con- 
straints. For example, in Figure [T|^c), if task t(u2i) fails, 
we might want to replace {1(1*19), 1(1*17), t(u5)} with 
{t('"22), 1(^20), t(ui6), t(u6)}. In general, we will therefore 
want to specify the conditions monitored for failure, and 
the changes (additions, removals) that must be seen in 
the successor configuration when failure occurs. The above 
adaptation requirement can then tell us that if we are running 
the configuration Si in Figure [TJc), and the system fails to 
satisfy t(w2i), then it could adapt from 5*1 to 6*3. Note that 
an adaptation requirement (T, A, D) might then be thought 
of as a a simple operator in AI planning, where T is trigger 
condition, while A and D are add/delete lists. 

Definition III.4. An adaptation requirement is an operator 
of the form (T, A, D), where T is a set of requirements 
present in the initial configuration (which are monitored to 
fail) while A and D are, respectively, sets of requirements 
that must be present and absent in the final configuration, if 
the operator applies. 

Note therefore that if operator (T, A, D) applied in going 
from configuration Si to S'i+i, then T U D C Si and A D 
Si — must hold, and analogously with S^+i. Note also that 
it is quite acceptable that multiple operators apply at the 
same time, when connecting Si to S'i+i, and that (as with 
the so-called ramification problem in AI), there may be 
additional changes needed in Si+i in order to make it a valid 
configuration. 



In the above sense, requirements are monitored, while 
adaptation requirements act as a control mechanism, which 
guides adaptation by changing the target requirements 
configuration that the adaptive system needs to satisfy. 

D. Comparison Criteria & Ranking of Roadmaps 

Ranking of roadmaps requires the identification of com- 
parison criteria, and the application of a decision rule which 
establishes a ranking on the basis of criteria. Comparison 
criteria are either optional requirements or preferences. 
Preferences can be individually added to A, or can be 
obtained through the relaxation of requirements, or from 
softgoals. Preferences are illustrated in Figure [T|d), where, 
e.g., t(ui6) is strictly preferred to \{ui-j), which indicates 
that, for this criterion only, a configuration having the former 
task is strictly more desirable than the configuration having 
the latter task. 

1 ) Preferences through Probabilistic Relaxation: Contin- 



uing the earlier example (cf., QII-B3 i, the upper bound on 
t2.c in q(t2x < (l.l/3)(wi,m_3 + + vi,rn-i)) may 

still be too idealistic, as callers may provide information of 
very different quality about the incident location. 

Probabilistic relaxation of a quality constraint is done in 
two steps. Firstly, the variable constrained in q is redefined 
as a random variable, and an assumption is made on the 
probability distribution of that random variable. Adding 
k(i2,c Af{60sec,4:5sec^)) to A makes of ^2,0 a random 
variable which follows a normal distribution. Secondly, the 
quality constraint to be relaxed is removed from A, and a 
new quality constraint is added. The new constraint specifies 
a bound not on the value of the now random variable, but 
on the probability that its value is in some range. Since we 
made i2,c into a random variable in the first step, we now 
replace q(i2,c < (l.l/3)(ui,,„_3 + + wi,m-i)) with 

q(-P(^2,c < (l-l/3)(l'l,m-3 + + l^l,m-l )) > 0.90), 

that is, we now require that the minimal probability should be 
0.90 for t2.c to be at most 110% of its three-month average. 

Random variables and quality constraints thereon play 
an important role in decision-making, as we use them 
to set desired probability levels over random variables. 
In more informal terms, this means that we can write 
quality constraints and domain assumptions which reflect, 
respectively, the confidence that we desire to reach in relation 
to system behaviors, and confidence that we actually have. 
Figures [TJc)-(d) indicate that 1(^7) operationalizes the quality 
constraint q(P(e < 0.10) = 0.8), while t(ug) operationalizes 
q(P(e < 0.10) — 0.2). The two quality constraints suggest 
that the two tasks result in different probabilities of having 
less than 10% of erroneous identifications of available ambu- 
lances. Figure [TJd) further indicates the level of satisfaction 
with each of the two probability levels. 

2) Preferences through Fuzzy Relaxation: Fuzzy relax- 
ation of a quality constraint involves two steps. In the 
first step, the quality constraint is removed, and a fuzzy 



membership function is defined over the variable from the 
removed quality constraint. In the second step, a softgoal 
is defined over the variable from the relaxed requirement. 

Consider again q(t2.c < (l.l/3)(wi,m-3+wi^,„-2+i'i,m-i)) 
and we now apply fuzzy relaxation. We start by removing 
this quality constraint from A. A fuzzy membership function 
over t2.c, denote it p{t2.c), depends on how stakeholders 
evaluate, in terms of desirability, the various values of t2,c- 



E.g., we could use fJ.{t2,c) 



so that the higher the 



value of t2^c, the lower p(t2.c) is, which reflect the idea 
that the more time it takes to identify an incident location, 
the more the stakeholders are dissatisfied, whereby their 
satisfaction increases as t2,c approaches (another example 
of a satisfaction function is in the upper part of Figure [Tfd)). 
If we adopt p as defined, we have removed the quality 
constraint on t2.c and we quantify satisfaction as a function 

of i2,c- 

To finish with the fuzzy relaxation of the quality constraint 
on ^2,0 a softgoal needs to be added to the requirements 
database over values of i2,c- Softgoals have had various 
definitions in RE, but there seems to be agreement on their two 
properties: (i) they are used for the comparison of alternatives, 
and (ii) they are vague, as they refer to some desirable values 
of variables, even though it may not be clear which exact 
values, or of which variables. E.g., Response time should be 
low is a typical softgoal, where the variable is suggested, 
but it is not clear which specific range of its values qualify 
as low; in the softgoal High safety, not only is it not clear 
how to measure safety, it is also not apparent when safety is 
high. When used in fuzzy relaxation, a softgoal is defined 
over a known variable: in our example, it is reasonable to 
prefer lower over higher values of i2,c, and we consequently 
have the softgoal 

S( LET Xi = VAL(S'i,t2,c) AND X2 = VAL(S'2, t2,c); 
IF fi{xi) > fl{x2) THEN ADD 
{k(t2,c = Xi),k{t2,c = X2), 
k(t2,c = y W{t2,c = X2)} 

TO A; ) 

where VAL(S'i, t2.c) returns the value of t2,c in ^i. Although 
the formulation above seems very different from saying 
"Low t2,c", this is precisely what it does, as long as /i(t2.c) 
decreases as t2,c increases. >- denotes the strict preference 
relation, and k(t2.c ^ Xi) >- k(f2,c — 2^2) says that satisfying 
k(i2.c = a^i) is strictly more desirable than satisfying 
k(i2.c = 2:2). The important point to see is that the softgoal 
specifies a macro which generates domain assumptions and 
preference relations. For any two configurations 5*1 and ^2, 
the macro compares the satisfaction (returned by satisfaction 
function fi) with values that t2.c has in each of those two 
configurations. Depending on the comparison between these 
values, the macro adds two domain assumptions and a 
preference relation to A. The reason we add them to A 
and not individual configurations is because we can add one 
of these domain assumptions only if doing so does not violate 



the conditions that a configuration must satisfy (i.e., adding 
one of these domain assumptions may make a configuration 
inconsistent, and thus no longer a configuration at all). The 
macro above ensures that if we compare two configurations. 
Si and 5*2, t2.c obtains the value xi in 5*1 and the value X2 
in 5*2, then we will prefer over this criterion (independently 
of other criteria) the configuration in which t2.s obtains the 
value which results in higher satisfaction. The macro thus 
conveys the idea that, whenever we are given two values of 
t2.c, we prefer the one that we are more satisfied with. 

Fuzzy relaxation of a quality constraint over a variable 
V thus works by (i) removing the quality constraint on v, 
(ii) adding a fuzzy membership function /i(ti) on v, (iii) 
interpreting as the level of satisfaction with the value v, 
and (iv) adding a softgoal macro which generates preference 
relations that reflect the shape of /i. 

3) Preferences from Softgoals: Not all softgoals are 
macros used in fuzzy relaxation. A softgoal can be introduced 
in A even if we do now know the exact variable it refers 
to, or the exact range of values that it makes desirable. Very 
broad softgoals are allowed, such as 

S(pi7: Ambulances should quickly arrive at incidents) 

where we write p because the content of the softgoal is not a 
propositional variable as in a goal or task, since it is not clear 
from pi7 how to measure the time of arriving to incident 
scenes (e.g., does it begin at call reception, or at ambulance 
mobilization?) and it is not clear when a time to arrive at an 
incident counts as quick. There are two ways to approximate 
such softgoals: by refinement or by satisfaction functions, 
and both can result in preferences being added to A. 

When a softgoal is refined, it is treated just as any other 
requirement. E.g., we may define the following refinement 

of S(pi7) 

(iih.e < 15min); 

k(q(t7,e < 15min) S(pi7)); 

k(t7,e = tl,c + t2,c + t-i,c + t4,c + ^S.e); 

where we refined the softgoal with the quality constraint 
over the quantitative variable e (i.e., if we satisfy q(t7.e < 
15min) then the if-then domain assumption above, with 
implication, tells us to deduce 3(^17)), which is itself a 
function of times introduced before. We could find another 
refinement of 3(^17), and have a preference between the two. 

A softgoal can be approximated using a satisfaction func- 
tion, and by proceeding in a similar way to fuzzy relaxation. 
Given 3(^17), we decide which variable it refers to, and we 
assume it is t7.e, such that k(q(t7^e < 15min) — 3(^17)). 
Secondly, we remove the softgoal 3(^17). Thirdly, we define a 
function /ii (i7,e), and we interpret the value given by pi (t7,e) 
as the level of satisfaction with the value ^7 e- Fourthly, we 
add a softgoal macro over ti^e- 



3( LET Xi = VAL(Si,f7,e) AND X2 = VAL(5'2, t7.e); 
IF m{xi) > tJ,i{x2) THEN ADD 

{k(t7,e = Xl), W(t7.e = X2) , 
k(t7,e = Xl) >~ W{t7.e = 2:2)} 

TO A; ) 

This case is also illustrated with the softgoal 3(?Z'i) and 
function fj,{tx) in Figure [TJd). 

4) Use of Criteria for Ranking: Given a set of criteria 
and roadmaps, two kinds of decision rules are needed: (i) to 
establish a ranking of configurations, from the most desirable 
to the least desirable, in a roadmap; (ii) to establish a ranking 
of roadmaps. RPAS, roadmap, and configuration concepts 
specify no particular decision rule. This is intentional, as no 
universal decision rule can be given: every decision rule gives 
one or more criteria priority over others, so that domain- 
and/or project-independent decision rules should be much 
more interesting. Note that the decision rule to apply will 
depend on how tradeoffs are resolved, through, among others, 
stakeholder negotiations, these concerns remain outside the 
scope of the general problem definition. 

Various decision rules for configuration ranking can be 
used, such as one of the following: 

Rl: Rank highest the configuration if S" maximizes the 
quantitative variable v, and rank other configurations 
in a descending order by value of v that each achieves: 
i.e., S s.t., MAX(i;) iff VS", S' is a configuration and 
max{'VAL{S, v)) > mflx(VAL(5', v)), where max returns 
the largest constant in a given set. 

R2: Same as Rl, but rank highest the configuration which 
minimizes v, i.e., rank from MIN(i>) to configuration 
which results in the highest value of v. 

R3: Same as Rl, augmented for the following condition: 
the chosen configuration should satisfy the maximal 
number of optional and preferred requirements, where 
in a preference relation (j) y ip or (f> ^ tp, (p is the 
preferred requirement. 

Rl and R2 ignore preferences and optional requirements 
which are independent of v, and both give highest priority to 
the value of a chosen variable. In that case, the decision rule 
requires us to solve a single-objective optimization problem. 
The third rule is significantly different, as it has two high 
priorities, namely the value of the chosen quantitative variable 
and the number of optional and preferred requirements. The 
application of the third rule above requires the resolution of 
a multi-objective optimization problem. 

The decision-rules that ranks roadmaps focuses on the 
properties of entire roadmaps. Maximization or minimization 
of a quantitative variable can now be extended over an entire 
roadmap, whereby we may ask that optimization satisfies 
constraints on efficiency of adaptations. E.g., the decision 
rule may be as follows: 

R4: Choose roadmap TZ if (i) it maximizes the sum of values 
of the quantitative variable v over all configurations in 
TZ, under the constraints that (ii) v must never fall below 



value X in R, and (ii) no configuration in TZ differs from 
the configuration which immediately precedes it by more 
than y requirements. 
R4 is a decision rule pattern, where a concrete rule is 
obtained by setting x and y to constants. R4 illustrates that 
constraints need not be limited on individual configurations, 
but also on the structure of the roadmap, as it limits the 
number of changes that can be performed, which may reflect 
the necessity to conserve resources during adaptations. 

It is important to note that the choice of a roadmap 
does not impose the sequence of configurations that the 
system should follow: adaptive behavior means that, e.g., 
if we adopt rule R4 above, the system will start from the 
configuration in which the domain assumptions are consistent 
with the conditions in the environment of the system. It will 
then adapt according to the satisfaction/failure of monitored 
requirements. It may be relevant to dynamically (at runtime) 
compute new configurations, the discussion of which we 
leave as an open issue. 

IV. Departures from Prior Work 

The widely accepted general requirements problem def- 
inition is Zave & Jackson's fT6| (ZJ hereafter), stating 
that RE should produce a specification (S) of a design of 
the system-to-be, which ensures that the system-to-be is 
consistent with domain assumptions (A') and together with 
them entails requirements (R): i.e., that K, S \- R. This 
definition emphasizes two properties: (i) consistency, in that 
the operationalization of requirements, i.e., K U S must be 
consistent; and (ii) achievement of requirements, as U 5* 
are only acceptable if they are sufficient to deduce R. 

For an example of ZJ problem and solution, cf.. Figure 
[TJa). Assume that all goals there are the set R' , all domain 
assumptions K' , and all tasks S". Given R! and D' initially, 
the ZJ problem says that we should find tasks S C S' which 
satisfy a consistent subset D C D' of domain assumptions, 
and a consistent subset of requirements R C R'. Any one 
column among 5*1, ^2, and 5*3 in Figure [TJc) is a consistent 
set of domain assumptions and tasks which satisfy a set of 
consistent goals (i.e., Vi, l<i<3, Si=KU S), so that 
any one of these is a solution to the ZJ requirements problem. 
This can be verified by looking at the conflict and conditional 
relations in Figures [T|a)-(c). 

There is in the ZJ problem formulation no information to 
define comparison criteria. We offered a revised definition of 
the requirements problem IS) (JMF hereafter), which has a 
richer ontology (to account for concepts that have established 
themselves in RE, such as, e.g., goals and softgoals), allows 
inconsistencies between alternative configurations (each of 
which satisfies ZJ conditions), introduces preferences to allow 
the comparison of configurations in terms of desirability, and 
we argued that logical consequence in early RE is more 
adequately described by a nonmonotonic and paraconsistent 
consequence relation \J_i than h from classical logic. These 



revisions make it impossible to synthesize the requirements 
problem as if, S' h R, since consistency and achievement 
become only a part of the conditions that a solution should 
satisfy. Note that alternative solutions are indistinguishable 
in ZJ because of the absence of comparison criteria. 

Both the ZJ and JMF formulations of the requirements 
problem place considerable emphasis on properties which 
can be established from qualitative variables alone. With 
ZJ, the aim was to design one solution which is consistent 
and achieves requirements. With JMF, the aim was to design 
several configurations, all of which are consistent and achieve 
a threshold (i.e., all mandatory requirements), then proceed to 
decision-making, that is, compare configurations in terms of 
which preferred and optional requirements they satisfy, then 
choose one of them. Now, the aim is to choose roadmaps, 
whereby the configurations in a roadmap all are consistent 
and achieve requirements (as in ZJ), but also distinguish 
mandatory from optional requirements and can be compared 
in terms of preference (as in JMF). By satisfying Consistency 
and Qualitative threshold achievement, each configuration in a 
roadmap satisfies the ZJ conditions. By satisfying Conformity 
in addition, every configuration satisfies all properties that 
a candidate solution should satisfy in JMF. From there on, 
the departures of the configuration, adaptation requirement, 
roadmap, and RPAS concepts from ZJ and JMF are: 

1) A configuration satisfies Quantitative threshold achieve- 
ment. Dominance, and Minimality, in addition to 
Consistency, Qualitative threshold achievement, and 
Conformity. 

2) Decision rules for the ranking of configurations and 
of roadmaps can be formulated as an optimization 
problem, where the aim is to optimize one or more 
quantitative variables. This was not of interest in ZJ, 
and was very limited in JMF. 

3) There are new kinds of preferences and tradeoffs to 
consider. While a configuration may give an optimal 
value of a variable in one roadmap, we may prefer 
another roadmap, which fails to include that config- 
uration, but ensures some suboptimal, but acceptable 
value of the variable over several configurations in 
the roadmap. Instead of focusing on the desirability 
of individual solutions, it is necessary to look at the 
desirability of roadmaps. 

As the problem of designing, finding, and ranking 
roadmaps, RPAS reflects the consequences of adaptation 
behavior: a roadmap is a set of configurations, which need 
not have a predefined sequence, but adaptation requirements, 
while the system needs to be designed so as to be able to 
monitor requirements, and satisfy adaptation requirements 
by controlling its behavior, whereby it switches between the 
highest ranking, yet feasible configurations. 



V. Formalization 

The aim in tMs section is to define the modehng language 
used throughout the preceding sections, then define additional 
tools necessary to present the formal definition of the 
configuration concept. 

A. Language 

The set of requirements £ is the union of four disjoint sets 
of formulas: simple requirements on propositional variables 
simple requirements on quantitative variables , simple 
softgoals £^ , and complex requirements C'-' . 

Every simple requirement on a propositional variable, 
i.e., every a G C^, satisfies the following BNF specification: 



k{p) I g{p) I t(p) 



(V.l) 



where p is a symbol for a propositional variable. A re- 
quirement over a propositional variable can be a domain 
assumption (k), a goal (g), or a task (t). The informal reading 
of the members of £^ is 

k(p): it is believed that p is satisfied; 

g{p): it is desired that p be satisfied; 

t{p): the execution of the task makes p satisfied. 
In the readings above, "can be" is replaced by "is" when 
the requirement is mandatory (see Complex requirements 
below). 

Every simple requirement on a quantitative variable, 

i.e., every b E , satisfies this BNF specification: 

X ::= n\v\x + x\ x — x\x-x \ x/x \ x^ (V.2) 
y ::= a;>a;|a;<a;|a:: = a;|a;>a; 

\x<x\xy^x\x^ pdf (V.3) 

h ::= k(y) | q(y) | tiy) (V.4) 

where n is a real number, u is a quantitative variable, and 
pdf is a probability density function. The informal reading 
is: 

k(j/): it is believed that the condition y is satisfied; 

q(y): it is desired that the condition y be satisfied; 

t(?;): the execution of the task makes y satisfied. 
Again, "can be" is replaced by "is" above, when the 
requirement is mandatory. 

Simple softgoals are kept outside £^ and £^ because the 
natural language statement in a softgoal (e.g.. High usability, 
High performance), denoted p, refers to some desirable values 
of variables in such a way that it is not clear which exact 
values, or how the values of these variables can be observed 
or measured. Every c G satisfies: 



s{p). 



(V.5) 



An p is called the content of a softgoal, and is a vague 
proposition. By being vague, p is neither a propositional 
variable, nor a quantitative variable, nor a condition on 
quantitative variables. The symbol used is intentionally 



different from those inside domain assumptions, goals, quality 
constraints, and tasks. 

A complex requirement relates simple requirements 
and/or softgoals, or is a mandatory or optional requirement. 
Every h e satisfies the BNF specification 
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(V.6) 
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The specification of complex requirements introduces the 
convention that every complex requirement that has the 
implication connective is a domain assumption, as we assume 
that requirements or variables are related in refinement, 
conflict, or otherwise. Note that the quantitative refinement 
relation is specified as k{y), where y is a condition in which a 
quantitative variable is equated to a function over quantitative 
variables. 

We use lowercase letters of the Greek alphabet to denote 
generic requirements, members of £ = U U £^ U 
£'-^. Uppercase Greek letters denote sets of requirements. 
Preferences over simple requirements and softgoals are kept 
in the separate set. 

The set of preferences V includes all preference relations 
over simple requirements and/or softgoals; every w E V 
satisfies the specification 



w 



d'^ dld-^ dldi 



(V.ll) 



Note from this specification that we do not allow preferences 
between complex requirements, and we not allow a preference 
to be mandatory or optional, to participate in a refinement, 
or in a conflict. 

Definition V.l. The language is the tuple (P, M, V, P, C, V), 

where C the set of requirements which satisfy the BNF 
specification in Equations |Kif[\{iQ| and V is the set of 
preferences which satisfy the BNF specification in Equation 



V.ll whereby the propositional variables in requirements 
and preferences come from the set P, numbers from the set 
M of real numbers, quantitative variables from V, and vague 
propositions from P. 

Definition V.2. Any A ^ CUV is a requirements database. 

B. Consequence Relation 

We use the Techne consequence relation. 

Definition V.3. The consequence relation j{7j is such 
that, for n C £, (j) E C and x G {</), _L}." 
. IV \^ (f> if (j) E H, or 

. xifyi<n, (j), and /((AiLi ^^ G n, 

for y G { "empty", o, «}. 



The consequence relation \^ is sound with regards to 
standard entailment h in classical prepositional logic, but is 
incomplete in two ways: it only considers deducing positive 
atomic facts, and no ordinary proofs based on arguing by 
contradiction go through, thus being paraconsistent. 

C. Operationalization Functions 

We have two operationalization functions, respectively for 
requirements over quaUtative and over quantitative variables. 
The purpose of an operationalization function is, given a 
requirement (f) and a set of requirements X, to return, if 
it exists, every set F C X which satisfies the following 
conditions. If ^ is a requirement over a qualitative variable, 
then Y includes only those domain assumptions and tasks 
which are necessary to deduce </>. If is a requirement over 
a quantitative variable, then Y includes only those domain 
assumptions and tasks which ensure that the condition in 
(j) is satisfied, when all of the variables in that condition 
are replaced by the values that they are assigned by the 
requirements in Y . 

To define operationalization functions, we define below 
the Select function and one useful set. We assume that O = 
{k, g,q,s, t} and we denote p{X) the powerset of X. 

Definition V.4. The select function 

Select : O X { "empty", o, m} x p(£) — > p{C) (V.12) 
is defined as follows, for x e O, ye {"empty" , o, m}, and 

nc£.- 

Select{x, y, n) ^ {(/> I x{(j))y e H} . (V. 13) 

To simplify notation, we use the following abbreviation: 

5eZert(x,y,n) = n)[. (V.14) 

Given a set of expressions, the Select function returns its 
subset, in which all members have the labels x e O and 
y e {" empty ",o,m}. 

Definition V.5. Useful set: Let IT C £ and x e O: 

CON{IL) = {$ C n I $ 1/^ _L anJ y A5^ C $} (V.15) 

CON{Il) is the set of all consistent subsets of U, whereby 
every one of these subsets must include all mandatory 
requirements from A. 

The reason why every <f) s CON (11) must include 
all mandatory requirements is that we require the set of 
mandatory requirments to be consistent and, as we will see 
below, to be included in all operationalizations, because an 
operationalization must not be inconsistent with mandatory 
requirements. 



Definition V.6. The qualitative operationalization function 



Op: U^^ 
vx,y 



P P 



U A- 



(V.16) 



for y, w e { "empty", o, m}, x € {g, q, s], and z e {k, t}, is 
defined as follows: 

Op [ G U a][ I ='{n € coA/(A) I n <^ 

V vx,y / 

and n \ {0} C IJ A^, 

VZIV 

and ^$ C n, $ h> 4)}. {Nil) 

Every member of the set Op{(b) is a minimal consistent 
set of tasks and domain assumptions that is sufficient to 
operationalize the goal, quality constraint, or softgoal <j). 
Informally, Op{4>) tells us all ways in (i.e., subsets of) A of 
satisfying a goal, quality constraint, or softgoal, which are 
consistent with all mandatory requirements. 

There can be cases when i/i is a requirement over quan- 
titative variables and is satisfied, but the function Op finds 
no operationalizations thereof. This happens if there are 
no qualitative refinements of (j). We use the quantitative 
operationalization function to identify requirements which 
satisfy an G C'^ . 

Definition V.7. The quantitative operationalization func- 
tion 



Ov. n A) 




(V.18) 



for y,we{ "empty", o, m}, x G {k, q, t}, and z G {k, t}. 

Let Vi, Hi G M, Vi G V, where every Vi is a variable 
which appears in (j) and there are m such variables in (j), 
i.e., 1 < i < m. Ov is defined as follows. 

neOv{(t)e C^) if and only if 

1) n G CON{A), i.e., n is consistent, 

2) {x{vi = ni)y G £^ I 1 < i < m} C n, i.e., H 
includes a set of requirements over the m quantitative 
variables in (j), 

3) VI < i < TO, one or more of the following hold 

a) x{vi = ni)y G Uvz.wA^', i.e., x{vi = ni)y is 

among domain assumptions and tasks in A, 

b) 3$ G Ov{x{v^ = n^)y) s.t. $ C n, i.e., a subset 
o/n is a quantitative operationalization ofx{vi = 

n.)y, 

c) 3$ G Op{x{vi = ni)y) s.t $ C n, i.e., a subset 
of II is a qualitative operationalization of x{vi = 

n.)y, 

4) and if we replace every variable Vi in </> with the 
constant rij, then the condition in (j) holds. 



Every member H of Ov((f)) is a consistent set which includes 
all requirements which (i) are ope rationalized, (ii) assign 
values to every quantitative variable vi, . . . , Vm in 4>, and (Hi) 
assign such constants ni, . . . , to the variables Wi, . . . , v„i 
that the functional relation specified over these variables in 
(j) holds. Ov{(f)) tells us all combinations of requirements 
which assign such constants to all variables in (j) that (j) is 
satisfied. 

D. Macros 

Macros automatically change the requirements database 
when it already contains some specific requirements, or when 
specific values of quantitative variables are observed. There 
are softgoal macros and quantitative conflict macros. 

Macros rely on the special monitoring function VAL. Given 
a set of requirements X C A, and a quantitative variable 
V, if there are tasks and domain assumptions in X which 
assign a value n e M to u (e.g., a task such that \{v = n) 
where n is a constant), then n £ YAL{X, v). 

Definition V.8. The monitoring function 

YAh:p{A)xV — > p(R) (V.19) 

is defined as follows, for X C A, v ^V, x G {Ic, q, f}, and 
ye {"empty", o,m}: 

YAL(X, v) ={n eR\3Y CX s.t. 

Y e Ov{x{v = n)y) U Op{x{v = n)y)} 

(V.20) 

VAL{X, v) is a set of all constants that are assigned through 
qualitative or quantitative operationalizations in X to v. 

The quantitative conflict macro applies to any quan- 
titative variable v for which VAL(A, v) ^ 0. As long as 
|val(A,?;)| > 2, the macro adds a conflict relation between 
every pair of assignments of different values to v. E.g., if 
VAL(A,w) = {3,7}, this means that there is at least one 
operationalization which assigns the constant 3 to v, and at 
least one other operationalization which assigns the constant 
7 to V. The macro will add two quality constraints, q{v = 3) 
and q{v = 7) to A, and will add the mandatory conflict 
k(q(?; = 3) A q(w = 7) ^ -L)". 

Definition V.9. For every quantitative variable v € V such 
that VAL(A, v) 7^ 0, there is the following quantitative 
conflict macro: 

k( IF |vAL(A,i;)| > 2 THEN\/xi,X2 G VAL(A,u) ADD 
{q{v = xi),q{v = xa), 
k{q{v = i-i) A qiv = xa) ^ -L)"*} 
TO A; ). 

The purpose of the quantitative conflict macro is to ensure 
that no quantitative variable obtains two different assignments 
in one configuration. 

The softgoal macro applies to any quantitative variable 
V for which val(A,w) 7^ and for which there is a 



satisfaction function p{v). This is the case when there is 
in A an operationalization of a requirement which assigns 
a value to v and a domain assumption which defines a 
variable v' as the output of the satisfaction function on v, 
i.e., 3k{v' — p{v)) E A. The softgoal macro automatically 
adds preference relations between sets of requirements 
which operationahze requirements that assign constants to 
V, whereby the preferences are defined to reflect the values 
retumed by fi. 

Definition V.IO. For every quantitative variable v € V such 
that VAL(A,w) 7^ and 3k{v' = fi{v)) e A, where p is 
informally interpreted as a satisfaction function, there is the 
following softgoal macro: 

sf 'ixi,x2 e val{A,v) 

IF fl{xi) = fJ-ix'z) THEN ADD 

{k{v = xi),k{v = X2), 
k{v = xi) ^ k{v = X2)} 

TO A; 

IF fi{xi) > fl{x2) THEN ADD 

{k{v = xi), k{v = X2), 
k{k{v = xi) A k{v = X2) -L), 
k{v = xi) >- k{v = X2)} 

TO A; ). 

Two remarks are in order. Firstly, note that the preferences 
are added to reflect the values not of v but of the satisfaction 
level fj.{v) on v. When the satisfaction levels are different (the 
second case in the softgoal macro), then a conflict relation 
is introduced as well, which will ensure that a configuration 
does not satisfy two assignments of different constants xi and 
X2 to V whereby these different assignments are not equally 
preferred (i.e., p{xi) ^ p{x2)). Secondly, note the difference 
between the definition of the softgoal macro above, and the 
macro we used earlier (cf., j ]III-D2[ ): there, the macro was 
simpler because if made two assumptions which we do not 
make above, namely, (i) we assumed that we already knew the 
configurations, and (ii) we assumed that each configuration 
was such that the variable v was assigned exactly one constant 
in each of the configurations. 

E. Configuration Concept 

Definition V.ll. A configuration S, defined from the re- 
quirements database A, is a set 

S Q{j for xE{k,t}, yE{ "empty", o, m} (V.21) 

of domain assumptions and tasks, which satisfies the follow- 
ing properties: 

1) Consistency: S _L; 

2) Qualitative threshold achievement: 

ycj) e A^, z e {g, s}, 3n e Op{cj)) such that n c S; 

3) Quantitative threshold achievement: 

ycj) G A^, 3r e Ov{(j)) such that T C S; 

4) Conformity: A^ U A^ C S; 



5) Dominance: J^S' s.t. both S and S' satisfy conditions 
1^ above, S C S', and 3A° = S' \ S, s.t. A° ^ 9 
and X e {k, t}; 

6) Minimality: ^S' such that S' satisfies the conditions 
1-5 above and S' C S. 

The Threshold achievement property requires that a 
configuration satisfies all mandatory goals, quality constraints, 
and softgoals. Satisfaction depends on the presence of 
operationalizations in S, for each of the mandatory goals, 
quality constraints, and softgoals. 

The Conformity property asks that all strict domain 
assumptions are not violated and all mandatory tasks are 
executed. The Achievement and Conformity properties ensure 
that the configuration satisfies all that must be satisfied. 

According to the Dominance property, every configuration 
will be maximal with regards to optional requirements. This 
property formalizes the idea of the optional relation, as 
holding on requirements which are desirable to satisfy, but 
can be violated. A configuration should include as many 
defeasible domain assumptions and as many optional tasks, 
up to the point at which adding any further defeasible domain 
assumptions and/or optional tasks violates the Consistency, 
Qualitative and Quantitative threshold achievement. Confor- 
mity, or Minimality properties. The Dominance condition 
ensures that every configuration is Pareto efficient with 
regards to optional requirements, as this condition makes it 
impossible to add optional domain assumptions and tasks to 
any S and still ensure that 5 is a configuration. 

The Minimality property requires that a configuration 
includes only the domain assumptions and tasks which 
are needed to satisfy exactly the Consistency, Threshold 
achievement. Conformity, and Dominance properties. 

F. Related Work & Discussion 

We have illustrated throughout the paper how the contri- 
butions here depart from prior efforts in the understanding 
of the requirements problem and solution concepts. The 
roadmap concept is inspired by our discussion of the role of 
contexts, time, and resources in the requirements problem for 
adaptive systems |10|. We have used Techne I?) here as a 
starting point and extended its syntax to allow requirements 
which place constraints on quantitative variables. This has 
resulted in a more general treatment of operationalization, as 
we have both qualitative operationalization and quantitative 
operationalization functions. As in the case of Techne, the 
formalism here does not provide a visual syntax, and is 
thus not itself a model language for early requirements 
in the same sense that, e.g., KAOS goal models ||4| and 
i* actor models ifTSi are. In this sense, same remarks 
apply as those that we had made when comparing Techne 
to KAOS, Tropos, and Two limitations of Techne are 
overcome here. Firstly, we can make explicit the constraints 
on quantitative variables. Secondly, Techne was informally 



criticized that it is blind to the distinction between stable facts 
and defeasible information: this is not the case, as optional 
domain assumptions here behave like defeasible information, 
while mandatory domain assumptions act like stable facts. 

In the rest of this section, we look at how the language 
presented in this paper can be used to model information 
that was recognized as crucial in the research into the 
relaxation of requirements |9|, [T?!, f2], the evaluation of 
their partial satisfaction L9|, and the monitoring and control 
of requirements Q, W2\ . The aim is not to suggest the 
language here as a general modeling language, but to show 
that it covers the main ideas presented in relation to the said 
topics. 

Fuzzy Relaxation. Baresi et al. associate every fuzzy 
operator with a predefined membership function. For example, 
if there is a quality constraint q(w < 6hrs) here (a goal 
G{v < 6hrs) for them, as they allow quantitative variables 
in goals), then relaxing it would amount to replace it with 
q(u </ 6hrs) (in their notation, G{v <f 6hrs)), where <f 
is a fuzzy operator. Their interpretation of i; </ 6hrs is 
that there is a fuzzy membership function /i which returns 
the level of satisfaction as a function of v, and the shape 
of II is predefined (for it is positive and constant until 

V = 6, then decreases up to the satisfaction value for some 

V > 6). The operator < / can be defined in our language 
by reproducing, in a domain assumption a function which 
has the form of the fuzzy membership function for </, as 
defined by Baresi et al. We can define as follows a macro 
which takes a fuzzy goal of the form Q{v </ n), with n e M, 
and transforms it into requirements that can be added to our 
requirements database A: 

\/Q{v <f n) WHERE V £V AND n G R 

ADD {k(«' = TO A, AND APPLY THE 

SOFTGOAL MACRO ON A and v, 

where v' is a quantitative variable, i.e., v ^V, and /i is a 
function which is defined according to the function pattern 
defined by Baresi et al. for the fuzzy operator <f. It is 
straightforward to define similar macros for all other fuzzy 
operators defined by Baresi et al. 

Baresi et al. also define binary connectives, such as fuzzy 
conjunction. These can be defined here as well, as functions 
of those variables, which are defined using fuzzy membership 
functions. Each binary fuzzy operator gives one function 
specified in a domain assumption and using an approximation 
relation. In the formalism from Baresi et al., one way to define 
fuzzy conjunction A/ between two variables vi and V2, each 
of which has an accompanying fuzzy membership function 
^(wi) and fi{v2), is as follows: fi{vi A/ 1^2) = IJ-ivi) ■ l^{v2)- 
In our language, /i(vi) and give satisfaction levels. The 
fuzzy conjunction connective between two quality constraints, 
respectively over variables vi and V2 is introduced in A as 
the domain assumption k(u3 — • ii{v2)), where is 

the joint level of satisfaction over variables vi and V2- 

Probabilistic Relaxation. To handle idealistic requirements. 



Letier & van Lamsweerde ||9) suggest the association of 
probability estimates to constraints on quantitative variables. 
This is what we allow in the language, and this has been 



illustrated earUer (cf., jlll-Dl 



Monitoring & Control Variables. It is on the basis of 
the ontology for requirements that we identify controlled 
variables: if a variable appears in a task, it is a controlled 
variable. Any variable can be monitored, but all variables in 
goals, quality constraints, and domain assumptions need to 
be monitored. 

Adaptation Rules, or equivalently, reconciliation tactics 
fSl, adaptive goals |2|, adaptivity mechanisms (13]. We have 
not discussed how they ought to be specified or actually 
implemented, but we have suggested how they can be 
identified. The roadmap adopted for a system gives a set 
of configurations. It consequently indicates what changes 
between two configurations, i.e., which requirements are 
dropped, which become optional, which others become 
mandatory, and so on. Differences between every two 
consecutive configurations in the roadmap specify the effect 
that adaptation rules should have, regardless of how they are 
specified or implemented. 

Limitations. While it may be possible to specify time 
and temporal constraints by having a quantitative variable, 
the values of which are defined by a clock and to map 
every configuration to a temporal interval, this would clearly 
not be to a convenient way to model temporal constraints 
on roadmaps. More appropriate in this respect may be 
requirements modeling languages built on top of linear 
temporal logic [4| or branching temporal logic |fT4| . It is, 
however, not clear at all how requirements models built 
with such languages relate to roadmaps, that is, are these 
requirements models describing constraints on a single 
configuration, or on parts of roadmaps. Techne has already 
been criticized for ignoring the notion of agent, and the fact 
that requirements belong to individuals which may thus be 
modeled as agents. We continue to ignore them here, mainly 
because they can be introduced in a straightforward manner, 
yet would complicate notation and presentation, without 
adding much to the main purpose of this paper. To add agents, 
consider first why they need to be added. If the aim is to 
help figure out who needs to negotiate requirements conflicts, 
then assume there is a set of identifiers for agents, and add a 
function which returns, for every requirement, one or more 
agents who agree on it. If the aim is to assign responsibilities 
of tasks to agents, then assume a set of identifiers for these 
agents, and define a function which maps every task to one 
or more agents responsible for its execution. Either of the 
two uses of agents has no influence on the structure of the 
roadmap problem, other than suggesting that RE does involve 
negotiation and the assignment of responsibilities. 



VI. Conclusions, Limitations & Open Issues 

We have presented two results. Firstly, by defining the 
configuration, adaptation requirement, and roadmap concepts, 
we have suggested a precise definition of the requirements 
problem for adaptive systems. We have related these concepts 
to the key notions from RE of adaptive systems, namely, 
monitoring, control, adaptation requkements, probabilistic 
and fuzzy relaxation. This led us to argue that there are 
fundamental differences between Zave & Jackson's and our 
conceptions of the requirements problem, and the require- 
ments problem for adaptive systems, its solution concepts, 
and the decision rules used to rank solutions. Secondly, we 
have used a simple modeling framework throughout the paper, 
based on Techne, and which serves as a proto-framework, 
being an illustration of features needed in future requirements 
modeling languages for early RE of adaptive systems. 

In addition to limitations, there is a number of interesting 
open issues. The shift to configurations and roadmaps 
suggests that research into extended planning and single- 
and multi-objective optimization may be a source for further 
advances in RE frameworks and tool support. It is necessary 
to look into how the roadmap requirements problem relates 
to mixed-integer programming, and mixed-variable program- 
ming, how to make adaptation rules on the basis of roadmaps, 
what decision rules may be relevant for decision-making in 
RE. Work is needed on the integration of probabilistic and 
fuzzy relaxation, monitoring and control within practical 
modeling languages, for early and late requirements phases. 
This paper will hopefully inform these future efforts. 
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